מאת גלעד ירון, SECOZ
IT Governance, Risk & Compliance (IT GRC)
ארגונים בני זמננו תלויים יותר ויותר בטכנולוגיות המידע והתקשורת. עובדה זו הופכת את הסיכונים העומדים בפני טכנולוגיות אלה למוחשיים ומשמעותיים יותר מאי-פעם. בשל כך חשוב לנהל סיכונים אלה באותה מידה בה מנהלים סיכונים תפעוליים אחרים בארגון. אבני היסוד של תהליך ניהול סיכוני טכנולוגיות המידע הן אותן אלה המשמשות בכלל תהליכי ניהול סיכונים, ללא קשר למהות הסיכון.
ניהול סיכונים מוגדר כתהליך זיהוי, הערכה, בחירת אסטרטגיית טיפול, צמצום ובקרה של הסיכונים העומדים בפני הארגון. ניהול סיכונים בכלל וניהול סיכוני טכנולוגיות מידע בפרט מתחילים ברוח ותרבות הארגון. עד כמה הארגון מוכן לקחת סיכונים? יש לזכור שבמקרים רבים סיכונים וסיכויים כרוכים זה בזה. הנכונות לקחת סיכון נקראת בשפת ניהול הסיכונים "תיאבון הסיכון" (“Risk Appetite”).
תחילה יש להגדיר מהם הנכסים אשר עומדים בפני סיכון. השימוש במושג "נכס" אינו תמיד אחיד. אנשי המחשבים נוהגים לא פעם להתייחס לרכיבים טכנולוגיים כאל נכסים. "הסיכון שהדיסק יקרוס". מאידך, במבט עסקי, הנכס אליו מתייחסים הינו התהליך (או המידע) העסקי אשר יפגע כתוצאה מקריסת הדיסק. הקשר של הרכיב הטכנולוגי לתהליך העסקי הינו קריטי בניהול הסיכונים.
מושגים חשובים, אשר לעיתים קרובות ההבדל בניהם אינו ברור הינם חשיפה (Vulnerability) ואיום (Threat). חשיפה היה ליקוי אשר ניצול שלו עלול לגרום נזק. איום הינו חשש לניצול החשיפה הלכה למעשה.
עבודות ומאמרים רבים נכתבו על חישוב הסיכון. בצורה פשטנית נתאר חישוב זה כמכפלה של הנזק העלול להיגרם כתוצאה מן האיום בסבירות שאיום זה יתממש. לא קל לחשב אף אחד מחלקי המשוואה. כיצד נדע להעריך את הנזק שייגרם לארגון מהתממשות הסיכון? שתי גישות קימות לסוגיה זו – הגישה הכמותית ("כמה זה יעלה לנו?") המעמידה מודלים כלכליים ומספריים שונים והגישה האיכותית ("נזק גבוה/בינוני/נמוך") המבוססת על ניסיון ודעת מומחים.
סוגיה לא פחות קלה הינה חישוב הסבירות שאכן הסיכון יתממש. כיצד ניתן לדעת מה ההסתברות לאירוע שאין לנו עליו מידע היסטורי? גם כאן ניתן לנסות ולמצוא סימוכין שונים, סטטיסטיים ואחרים, לחישוב או, לחילופין, להשתמש בניחוש מלומד
ישבנו, חשבנו, חישבנו והרי לפנינו רשימה של סיכונים בעלי ערכים שונים. מה עושים עמם עכשיו? לאחר מיון הסיכונים לפי ערכם ובטרם מתחילים בטיפול בכל אחד מהם, יש לקבל החלטה עקרונית על אופי הטיפול הנדרש. קימות מספר אסטרטגיות בהן אפשר לבחור:
- התעלמות ("לי זה לא יקרה") – אסטרטגיה שאינה מומלצת, אלא אם כן אתם יענים.
איתי: תדגיש שזה לא "קבלה" – כי אני קפצתי כשקראתי את זה...
- העברה – לא מדובר בגלגול אין סופי של האחריות מאחד לשני אלא העברת הסיכון לגורם חיצוני כגון ביטוח.
- טיפול – בחירת בקרות אשר יצמצמו את חומרת הנזק או את הסבירות שהסיכון יתממש.
(איתי: לדעתי כדאי להתייחס למונחים של בקרה מונעת ובקרה מפצה)
- קבלה – אופציה זו נשכחת במקרים רבים. בהחלט יתכן כי הארגון מוכן לחיות עם סיכון מסוים. יש לבחור באופציה זו רק לאחר שברור כי משמעות הסיכון ברורה למקבלי ההחלטות והאישור לבחור באופציה זו התקבל על יד הגורם עסקי.
בחירה בבקרות נכונות היא תהליך הדורש מחשבה. בעת בחירת הבקרות יש לבחון את המיומנות של הצוותים האמורים לתפעלן וכן לבדוק כמה קרובות הבקרות הנבחרות לאלה שכבר נמצאות בשימוש בארגון (טכנולוגיה חדשה כגון מערכת הפעלה שאינה מוכרת לארגון עלולה להוסיף בעצמה סיכון חדש). משוואה נוספת ופשוטה שלא תמיד עומדת מול עיננו בעת בחירת הבקרות הינה: עלות הבקרה צריכה להיות קטנה מעלות הנזק שאותה היא אמורה למנוע...
לאחר בחירת הבקרות המתאימות יש לעקוב אחר מימושם ויעילותם. ניהול ובקרה צמודים אחר מימוש בקרות אלה הינם חיוניים. בארגוני IT גדולים בארץ ובעולם מתחילים לראות היווצרותו של גוף חדש במסגרת ה-IT אשר אמון על ניהול סיכוני טכנולוגיות המידע. גוף זה עומד בפני עצמו או משולב כחלק מגוף הניהול המרכזי שלו שמות רבים כגון PMO, "משרדו של המנמר" ואחרים.
לא חשבתם לעזוב טור זה בלי מספר סטנדרטים, נכון? ובכן, בעולם ניהול סיכוני IT קיימים מספר סטנדרטים. הוותיק בניהם הינו הפרק השלישי בסדרת התקנים האנגליים הותיקה (שנמצאת בתהליכי אימוץ כתקן בינלאומי) – BS 77990-3 (27001/3 ISO). תקן חדש ומקובל מאוד הינו של ארגון הסטנדרטים האמריקאי - 800-30 NIST. אחרון אחרון חביב, החביב ביותר עלי, הינו תקן שבא מאוסטרליה. מספר תקנים מעניינים מגיעים אלינו מיבשת קסומה זו! התקן הוא ANZ-4360 - נסו ותיהנו.
|
